IBIS Macromodel Task Group Meeting date: 12 January 2016 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Avago (LSI): Xingdong Dai Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - There will be no ATM meeting on January 19th (next week) because of DesignCon and the associated IBIS summit. - Arpad noted that the following changes he had made to the ATM agenda's Pending BIRDs section: - BIRD179 "New IBIS-AMI Reserved Parameter Special_Param_Names" was removed from the list because it was Accepted by the Open Forum during the December 18, 2015 meeting. - A TBD entry was added for the "C_comp modeling with IBIS-ISS" topic that had been introduced by Randy Wolff and discussed in previous ATM meetings. - Arpad noted that Bob Ross had prepared a presentation on Voltage References in IBIS and asked to review it at today's meeting. -------------------------- Call for patent disclosure: - None. ------------- Review of ARs: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Radek: Motion to approve the minutes. - Arpad: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: New Redriver Flow BIRD: - Discussion: Arpad asked Fangyi if he had any updates on this topic. Fangyi said that he is working on a solution and preparing slides. He will distribute them when they are ready. Fixing [Pin Mapping]: - Walter: [sharing the presentation he plans to deliver at the DesignCon IBIS summit next Friday]. - Discussion: Walter's presentation highlighted a particular sentence in the [Pin] section of the spec: "The second column, signal_name, gives the data book name for the signal on that pin." Walter said this statement should have ramifications in terms of the way we allow IBIS [Component]s to connect things via the [Pin] section and the bus labels in [Pin Mapping]. The bus labels defined in the [Pin Mapping] section are generally identical to the signal_names from the [Pin] section. The spec does not require this, arbitrary bus label names can be created and used. However, this sort of indirection in the bus label names can lead to non- sensical connections that neither the spec nor the parser explicitly disallow. His presentation includes nonsensical cases in which an arbitrary bus label name is used to short [Pin]s with model names POWER and GND. He also pointed out an example in which the [Pin] section used the same signal_name for one POWER Pin and one GND Pin. He noted that it was self-evident that this should be a spec violation, given the signal_names = data book names statement. However neither the current spec nor the current parser explicitly prevented such nonsensical connections. Walter proposed two new rules to formally codify the intent of the spec: 1. All [Pin]s with the same signal_name must use the same [Model] name. 2. All POWER/GND [Pin]s connected to the same bus label must have the same signal_name. Walter stated that every IBIS [Component] he had ever seen with a [Pin Mapping] section had used bus label names identical to the signal_names. He felt that introducing these rules would not in practice break our rules about backward compatibility. He felt that it was likely a bug in the initial spec that these types of nonsense connections weren't already explicitly illegal. Walter also introduced the concept of a "Signal_names_are_bus_labels" option to explicitly state the case and also allow simplifications in the [Pin Mapping] section, such as not needing to include the POWER and GND [Pin]s in the [Pin Mapping] section. This might even be considered the default assumption (no need for the new option). Bus label names could still be used to further subdivide groups of [Pin]s that had the same signal_name (in this case it would be necessary to introduce bus label names different from the signal_name itself). Bob expressed general support for this enhancement, though he thought there might be a detail or two to be worked out with respect some of the interconnect discussions. Arpad objected to a statement on the final summary slide that these new rules were required to make [Pin Mapping] "useable." He stated that just because the model maker could do silly things didn't make [Pin Mapping] unusable, and used the analogy of mistakenly using a .connect statement in SPICE to connect different voltage rails (Bob agreed). He said that we usually wanted the parser to focus strictly on syntax, not enforcing reasonable models. Radek pointed out that that we have the parser check rules from the spec, and we could introduce new explicit rules. Additional open questions left from the discussion: 1. Radek asked if Walter also intended to clarify that only POWER [Pin] connected bus labels could be used in the pu_ref column, and only GND [Pin] connected bus labels could be used in the pd_ref column. That is, only a POWER [Pin] could be the pu_ref for an I/O Pin and only a GND [Pin] could be the pd_ref. Walter said that this was another decision that we could make, but that the example for bug 172 had provided a case in which one I/O Pin used VSS as its pu_ref and VDD as its pd_ref. It was an open question if we wanted to decide not to allow that. 2. In reviewing ibischk BUG 172 with Curtis and Bob, Radek had noticed an additional issue with the parser. The spec says that a POWER [Pin]'s entry in the [Pin Mapping] section should have its bus label specified in the pu_ref column. Similarly, a GND [Pin]'s entry should have its bus label specified in the pd_ref column. However, the current parser only issues a warning (not an error) if this rule is violated and a bus label is specified in one of the other columns. Should we have the parser report an error in this case? This may be part of the BUG 172 discussion. Discussion of Voltage References in IBIS: - Bob: [Sharing his presentation on the history of voltage references in IBIS. Presentation is now available in the ATM work archive. http://ibis.org/macromodel_wip/archive-date.html] - Discussion: Bob reviewed his presentation. He stated that IBIS was full of implicit references to "node 0" [referred to as 0.0V in his presentation]. The presentation covered a long list of IBIS keywords, terminal names, etc. Bob stated that for a variety of historical reasons and syntactical reasons (e.g., no separate reference node provided anywhere in the syntax) node 0 was an implicit reference for all of them. Ultimately, Bob suggested that fixing this would require an intensive page-by-page scrub of the spec to see exactly what had been intended in each case and how it could be resolved. Walter objected to Bob's interpretation. He said that the implicit references to zero arose out of the discussions of test fixturing for the measurement of I/V and v(t) curves. The test fixture assumes the pd_ref is tied to "0", but at simulation time things would be calculated with respect to the floating pd_ref node. Arpad also disagreed, and said that his recollection of [Voltage Range], for example, was that it was the voltage between the pu_ref and pd_ref terminals for the device, not between the pu_ref and absolute ground. Radek mentioned one example, A_gnd, and said he thought it was probably a mistake to have the expression "similar to SPICE ideal node '0'" in its description in the spec. He said it was actually a local ground reference that needed to be defined. He said it was important that all these implicit references be clarified. Everyone agreed that Bob's presentation provided good historical context for the discussion. - Arpad: Thank you all for joining. ------------- Next meeting: 26 January 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives